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(57) Abstract 

An apparatus and a method for routing data in a radio data communication system having one or more host computers 
(10), one or more intermediate base statios (20-52), and one or more RF terminals (100) organizes the intermediate base stations 
into an optimal spanning-tree network to control the routing of data to and from the RF terminals and the host computer effi- 
ciently and dynamically. Communication between the host computer and the RF terminals is achieved by using the network of 
intermediate base stations to transmit the data. 
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TITLE: A RADIO FREQUENCY LOCAL AREA NETWORK 

MPKfiRQtmP OF TH E INVENTION 

In a typical radio data communication system 
having one or more host computers and multiple RF 
terminals, communication between a host computer and 
an RF terminal is provided by one or more base 
5 stations. Depending upon the application and the 

operating conditions, a large number of these base 
stations may be required to adequately serve the 
system* For example, a radio data communication 
system installed in a large factory may require dozens 
10 of base stations in order to cover the entire factory 

floor • 

In earlier RF data communication systems, the 
base stations were typically connected directly to a 
host computer through multi-dropped connections to an 

15 Ethernet communication line. To communicate between 

an RF terminal and a host computer, in such a system, 
the RF terminal sends data to a base station and the 
base station passes the data directly to the host 
computer. Communicating with a host computer through 

20 a base station in this manner is commonly known as 

hopping. These earlier RF data communication systems 
used a single-hop method of communication. 

In order to cover a larger area with an RF data 
communication system and to take advantage of the 

25 deregulation of the spread-spectrum radio frequencies, 

later-developed RF data communication systems are 
organized into layers of base stations. As in earlier 
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KF data communications systems, a typical system 
includes multiple base stations which communicate 
directly with the RF terminals and the host computer, 
in addition, the system also includes intermediate 
stations that communicate with the RP terminals* the 
multiple base stations, and other intermediate 
stations. In such a system, communication from an RF 
terminal to a host computer may be achieved, for 
example, by having the RF terminal send data to an 
intermediate station, the intermediate station send 
the data to a base station, and the base station send 
the data directly to the host computer. Communicating 
with a host computer through more than one station is 
commonly known as a multiple-hop communication system. 

Difficulties often arise in maintaining the 
integrity of such multiple-hop RF data communication 
systems. The system must be able to handle both 
wireless and hard-wired station connections, 
efficient dynamic routing of data information, RF 
20 terminal mobility, and interference from many 

different sources. 
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SUMMARY O F THE INVENTION 

The present invention solves many of the problems 
inherent in a multiple-hop data communication system. 
The present invention comprises an RF Local-Area 
5 Network capable of efficient and dynamic handling of 

data by routing communications between the RF 
Terminals and the host computer through a network of 
intermediate base stations. 

In one embodiment of the present invention, the 

10 RF data communication system contains one or more host 

computers and multiple gateways, bridges, and RF 
terminals. Gateways are used to pass messages to and 
from a host computer and the RF Network. A host port 
is used to provide a link between the gateway and the 

15 host computer. In addition, gateways may include 

bridging functions and may pass information from one 
RF terminal to another. Bridges are intermediate 
relay nodes which repeat data messages. Bridges can 
repeat data to and from bridges, gateways and RF 

20 terminals and are used to extend the range of the 

gateways. 

The RF terminals are attached logically to the 
host computer and use a network formed by a gateway 
and the bridges to communicate with the host computer. 

25 To set up the network, an optimal configuration for 

conducting network communication spanning tree is 
created to control the flow of data communication. To 
aid understanding by providing a more visual 
description, this conf iguration is referred to 

30 hereafter as a "spanning tree" or "optimal spanning 

tree". 

Specifically, root of the spanning tree are the 
gateways; the branches are the bridges; and non- 
bridging stations, such as RF terminals, are the 
35 leaves of the tree. Data are sent along the branches 
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of the newly created optimal spanning tree. Nodes in 
the network use a backward learning technique to route 
packets along the correct branches. 

One object of the present invention is to route 
data efficiently, dynamically, and without looping. 
Another object of the present invention is to make the 
routing of the data transparent to the RF terminals. 
The RF terminals, transmitting data intended for the 
host computer, are unaffected by the means ultimately 
used by the RF Network to deliver their data. 

It is a further object of the present invention 
for the network to be capable of handling RF terminal 
mobility and lost nodes with minimal impact on the 
entire RF data communication system. 
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BRIEF DESCRIPTION OF THE DRAWING 

The FIG. 1 is a functional block diagram of an RF 
data communication system incorporating the RF local- 
area network of the present invention. 
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ireTOTT.ttn DEBCRI? »Tnw OP THE INVENTION 

The FIG. 1 is a functional block diagram of an RF 
data communication system. In one embodiment of the 
present invention, the RF data communication system 
has a host computer 10, a network controller 14 and 
bridges 22 and 24 attached to a data communication 
link 16. Also attached to the data communication link 
16 is a gateway 20 which acts as the root node for the 
spanning tree of the RF data network of the present 
invention. A bridge 42 is attached to the gateway 20 
through a hard-wired communication link and bridges 40 
and 44 are logically attached to gateway 20 by two 
independent RF links. Additional bridges 46, 48, 50 
and 52 are also connected to the RF Network and are 
15 shown in the FIG. 1. Note that, although shown 

separate from the host computer 10, the gateway 20 
(the spanning tree root node) may be part of host 

computer 10 * 

The FIG. 1 further shows RF terminals 100 and 102 

20 attached to bridge 22 via RF links and RF terminal 104 

attached to bridge 24 via an RF link. Also, RF 
terminals 106, 108, 110, 112, 114, 116, 118, and 120 
can be seen logically attached to the RF Network 
through their respective RF links. The RF terminals 

25 in FIG. 1 are representative of non-bridging stations. 

In alternate embodiments of the present invention, the 
RF Network could contain any type of device capable of 
supporting the functions needed to communicate in the 
RF Network such as hard-wired terminals, remote 

30 printers, stationary bar code scanners, or the like. 

The RF data communication system, as shown in FIG. 1, 
represents the configuration of the system at a 
discrete moment in time after the initialization of 
the system. The RF links, as shown, are dynamic and 

35 subject to change. For example, changes in the 



WO 93/07691 



PCT/US92/08610 



- 7 - 

structure of the RF data communication system can be 
caused by movement of the RF terminals and by 
interference that affects the RF communication links. 
In the preferred embodiment, the host computer 10 
5 is an IBM 3090 , the network controller 14 is a model 

RC3 250 of the Nor and Corporation , the data 
communication link 16 is an Ethernet link, the 
nodes 20, 22, 24, 40, 42, 44, 46, 48, 50 and 52 are 
intelligent base transceiver units of the type RB4000 

10 of the Norand Corporation, and the RF terminals 100, 

102, 104, 106, 108, 110, 112, 114, 116, 118 and 120 
are of type RT1100 of the Norand Corporation. 

The optimal spanning tree, which provides the 
data pathways throughout the communication system, is 

15 stored and maintained by the network as a whole. Each 

node in the network stores and modifies information 
which specifies how local communication traffic should 
flow. Optimal spanning trees assure efficient, 
adaptive (dynamic) routing of information without 

20 looping. 

To initialize the RF data communication system, 
the gateway 20 and the other nodes are organized into 
an optimal spanning tree rooted at the gateway 20. To 
form the optimal spanning tree, in the preferred 

25 embodiment the gateway 20 is assigned a status of 

ATTACHED and all other bridges are assigned the status 
UNATTACHED. The gateway 20 is considered attached to 
the spanning tree because it is the root node . 
Initially, all other bridges are unattached and lack 

30 a parent in the spanning tree. At this point, the 

attached gateway node 20 periodically broadcasts a 
specific type of polling packet referred to hereafter 
as "HELLO packets". The HELLO packets can be 
broadcast using known methods of communicating via 

35 radio frequency (RF) link or via a direct wire link. 
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in the preferred embodiment of the present invention, 
the RF link is comprised of spread-spectrum 
transmissions using a polling protocol. Although a 
polling protocol is preferred, a carrier-sense 
multiple-access (CSMA) , busy-tone, or any other 
protocol might also manage the communication traffic 

on the RF link. 

HELLO packets contain 1) the address of the 
sender, 2) the hopping distance that the sender is 
from the root, 3) a source address, 4) a count of 
nodes in the subtree which flow through that bridge, 
and 5) a list of system parameters. Each node in the 
network is assigned a unique network service address 
and a node-type identifier to distinguish between 
different nodes and different node types. The 
distance of a node from the root node is measured in 
hops times the bandwidth of each hop. The gateway 
root is considered to be zero hops away from itself. 

The unattached bridges are in a LISTEN state. 
During the LISTEN state, a bridge will listen to the 
HELLO messages that are broadcast. By listening to 
the HELLO messages, bridges can learn which nodes are 
attached to the spanning tree. The unattached bridges 
analyze the contents of the HELLO messages to 
determine whether to request attachment to the 
broadcasting node. In the preferred embodiment, a 
bridge attempts to attach to the node that is 
logically closest to the root node. In the preferred 
embodiment, the logical distance is based upon the 
number of hops needed to reach the root node and the 
bandwidth of those hops. The distance the attached 
node is away from the root node is found in the second 
field of the HELLO message that is broadcast. 

In another embodiment of the present invention, 
the bridges consider the number of nodes attached to 
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the attached node as well as the logical distance of 
the attached node from the root node. If an attached 
node is overloaded with other attached nodes, the 
unattached bridge may request attachment to a less 
loaded node. 

After attaching to an attached node, the newly 
attached bridge (the child) must determine its 
distance from the root node. To arrive at the 
distance of the child from the root node, the child 
adds the broadcast distance of its parent from the 
root node to the distance of the child from its 
parent. In the preferred embodiment, the distance of 
a child from its parent is based on the bandwidth of 
the data communication link. For example, if the 
child attaches to its parent via a hard-wired link 
(data rate 26,000 baud), then the distance of that 
communication link might equal, for example, one hop. 
However, if the child attaches to its parent via an RF 
link (data rate 9600 baud) , then the distance of that 
communication link might correspondingly be equal 3 
hops. The number of the hop corresponds directly to 
the communication speed of the link. This may not 
only take into consideration baud rate, but also such 
factors as channel interference. 

Initially, only the root gateway node 20 is 
broadcasting HELLO messages and only nodes 40, 42 
and 44 are within range of the HELLO messages 
broadcast by the gateway. Therefore, after the 
listening period has expired, nodes 40, 42 and 44 
request attachment to the gateway node 20. The 
unattached nodes 40, 42, and 44 send ATTACH. request 
packets and the attached gateway node 20 acknowledges 
the ATTACH. request packets with local ATTACH. confirm 
packets. The newly attached bridges are assigned the 
status ATTACHED and begin broadcasting their own HELLO 
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packets, looking for other unattached bridges. Again, 
the remaining unattached nodes attempt to attach to 
the attached nodes that are logically closest to the 
root node. For example, node 48 is within range of 
5 HELLO messages from both nodes 40 and 42. However, 

node 40 is three hops, via an RF link, away from the 
gateway root node 20 and node 42 is only one hop, via 
a hard-wired link, away from the gateway root node 20. 
Therefore, node 48 attaches to node 42, the closest 
10 node to the gateway root node 20. 

The sending of HELLO messages, ATTACH . request 
packets and ATTACH. confirm packets continues until the 
entire spanning tree is established. In addition, 
attached bridges may also respond to HELLO messages. 
If a HELLO message^ indicates that a much closer route 
to the root node is available, the attached bridge 
sends a DETACH packet to its old parent and an 
ATTACH. request packet to the closer node. To avoid 
instability in the system and to avoid overloading any 
20 given node, an attached bridge would only respond to 

a HELLO message if the hop count in a HELLO packet is 
greater than a certain threshold value, 
CHANGEJTHRESHOLD . In the preferred embodiment, the 
value of the CHANGEJTHRESHOLD equals 3. In this 
manner, an optimal spanning tree is formed that is 
capable of transmitting data without looping. 

Nodes, other than the gateway root node, after 
acknowledging an ATTACH, request packet from a 
previously unattached node, will send the 
ATTACH.request packet up the branches of the spanning 
tree to the gateway root node. As the ATTACH.request 
packet is being sent to the gateway root node, other 
nodes attached on the same branch record the 
destination of the newly attached node- in their 
35 routing entry table. When the ATTACH.request packet 
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reaches the gateway root node, the gateway root node 
returns an end-to-end ATTACH. confirm packet. 

After the spanning tree is initialized, the RF 
terminals listen for periodically broadcasted Hello 
5 packets to determine which attached nodes are in 

range. After receiving HELLO messages from attached 
nodes, an RF terminal responding to an appropriate 
poll sends an ATTACH. request packet to attach to the 
node logically closest to the root. For example, RF 

10 terminal 110 is physically closer to node 44. 

However, node 44 is three hops, via an RF link, away 
from the gateway root node 20 and node 42 is only one 
hop, via a hard-wired link, away from the gateway root 
node 20. Therefore, RF terminal 110, after hearing 

15 HELLO messages from both nodes 42 and 44, attaches to 

node 42, the closest node to the gateway root node 20. 
Similarly, RF terminal 114 hears HELLO messages from 
nodes 48 and 50. Nodes 48 and 50 are both four hops 
away from the gateway root node 20. However, node 48 

20 has two RF terminals 110 and 112 already attached to 

it while node 50 has only one RF terminal 116 attached 
to it. Therefore , RF terminal 114 will attach to 
node 50, the least busy node of equal distance to the 
gateway root node 20. 

25 The attached node acknowledges the ATTACH. request 

and sends the ATTACH. request packet to the gateway 
root node. Then, the gateway root node returns an 
end-to-end ATTACH. confirm packet. In this maimer, the 
end-to-end ATTACH. request functions as a discovery 

30 packet enabling the gateway root node, and all other 

nodes along the same branch, to learn the address of 
the RF terminal quickly. This process is called 
backward learning. Nodes learn the addresses of 
terminals by monitoring the traffic from terminals to 

35 the root. If a packet arrives from a terminal that is 
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not contained in the routing table of the node, an 
entry is made in the routing table. The entry 
includes the terminal address and the address of the 
node that sent the packet. In addition, an entry 
5 timer is set for that terminal. The entry timer is 

used to determine when RF terminals are actively using 
the attached node. Nodes maintain entries only for 
terminals that are actively using the node for 
communication. If the entry timer expires due to lack 

10 of communication, the RF terminal entry is purged from 

the routing table. 

The RF links among the RF terminals, the bridges, 
and the gateway are often lost. Therefore, a 
connection-oriented data-link service is used to 

15 maintain the logical node-to-node links. In the 

absence of network traffic, periodic messages are sent 
and received to ensure the stability of the RF link. 
As a result, the loss of a link is quickly detected 
and the RF Network can attempt to establish a new RF 

20 link before data transmission from the host computer 

to an RF terminal is adversely affected. 

Communication between terminals and the host 
computer is accomplished by using the resulting RF 
Network. To communicate with the host computer, an RF 

25 terminal sends a data packet in response to a poll 

from the bridge closest to the host computer. 
Typically, the RF terminal is attached to the bridge 
closest to the host computer. However, RF terminals 
are constantly listening for HELLO and polling 

30 messages from other bridges and may attach to, and 

then communicate with, a bridge in the table of 
bridges that is closer to the particular RF terminal. 

Under certain operating conditions, duplicate 
35 data packets can be transmitted in the RF Network. 
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For example, it is possible for an RF terminal to 
transmit a data packet to its attached node, for the 
node to transmit the acknowledgement frame, and for 
the RF terminal not to receive the acknowledgement. 
5 Under such circumstances, the RF terminal will 

retransmit the data. If the duplicate data packet is 

it 

updated into the database of the host computer, the 
database would become corrupt. Therefore, the RF 
Network of the present invention detects duplicate 

10 data packets. To ensure data integrity, each set of 

data transmissions receives a sequence number. The 
sequence numbers are continuously incremented, and 
duplicate sequence numbers are not accepted. 

When a bridge receives a data packet from a 

15 terminal directed to the host computer, the bridge 

forwards the data packet to the parent node on the 
branch. The parent node then forwards the data packet 
to its parent node. The forwarding of the data packet 
continues until the gateway root node receives the 

20 data packet and sends it to the host computer. 

Similarly, when a packet arrives at a node from the 
host computer directed to an RF terminal, the node 
checks its routing entry table and forwards the data 
packet to its child node which is along the branch 

25 destined for the RF terminal. It is not necessary for 

the nodes along the branch containing the RF terminal 
to know the ultimate location of the RF terminal. The 
forwarding of the data packet continues until the data 
packet reaches the final node on the branch, which 

30 then forwards the data packet directly to the terminal 

itself. 

Communication is also possible between RF 
terminals. To communicate with another RF terminal, 
the RF terminal sends a data packet to its attached 
35 bridge. When the bridge receives the data packet from 
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a terminal directed to the host computer, the bridge 
checks to see if the destination address of the RF 
terminal is located within its routing table. If it 
is, the bridge simply sends the message to the 
intended RF terminal. If not, the bridge forwards the 
data packet to its parent node. The forwarding of the 
data packet up the branch continues until a common 
parent between the RF terminals is found. Then, the 
common parent (often the gateway node itself) sends 
the data packet to the intended RF terminal via the 
branches of the RF Network. 

During the normal operation of the RF Network, RF 
terminals can become lost or unattached to their 
attached node. If an RF terminal becomes unattached, 
for whatever reason, its routing entry is purged and 
the RF terminal listens for HELLO or polling messages 
from any attached nodes in range. After receiving 
HELLO or polling messages from attached nodes, the RF 
terminal sends an ATTACH . request packet to the 
attached node closest to the root. That attached node 
acknowledges the ATTACH. request and sends the 
ATTACH.request packet onto the gateway root node. 
Then, the gateway root node returns an end-to-end 
ATTACH. confirm packet. 

Bridges can also become lost or unattached during 
normal operations of the RF Network. If a bridge 
becomes lost or unattached, all routing entries 
containing the bridge are purged. The bridge then 
broadcasts a HELLO.request with a. global bridge 
destination address. Attached nodes will broadcast 
HELLO packets immediately if they receive an 
ATTACH.request packet with a global destination 
address. This helps the lost node re-attach. Then, 
the bridge enters the LISTEN state to learn which 
attached nodes are within range. The unattached 
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bridge analyzes the contents of broadcast HELLO 
messages to determine whether to request attachment to 
the broadcasting node. Again, the bridge attempts to 
attach to the node that is logically closest to the 
5 root node. After attaching to the closest node, the 

bridge begins broadcasting HELLO messages to solicit 
ATTACH. requests from other nodes or RF terminals. 

The spread-spectrum system provides a 
hierarchical radio frequency network of on-line 

10 terminals for data entry and message transfer in a 

mobile environment. The network is characterized by 
sporadic data traffic over multiple-hop data paths 
consisting of RS485 or ethernet wired links and 
single-channel direct sequenced spread spectrum links. 

15 The network architecture is complicated by moving, 

hidden, and sleeping nodes. The spread spectrum 
system consists of the following types of devices: 

Terminal controller — A gateway which passes 
messages from a host port to the RF network; and which 

20 passes messages from the network to the host port. 

The host port (directly or indirectly) provides a link 
between the controller and a "host" computer to which 
the terminals are logically attached. 

Base station — An intermediate relay node which 

25 is used to extend the range of the controller node. 

Base station-to-controller or base station-to-base 
station links can be wired or wireless RF. 

Terminal — Norand RF hand-held terminals, 
printers, etc. In addition, a controller device has 

30 a terminal component. 

The devices are logically organized as nodes in 
an (optimal) spanning tree, with the controller at the 
root, internal nodes in base stations or controllers 
on branches of the tree, and terminal nodes as 

35 (possibly mobile) leaves on the tree. Like a sink 
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tree, nodes closer to the root of the spanning tree 
are said to be "downstream" from nodes which are 
further away. Conversely, all nodes are "upstream" 
from the root. Packets are only sent along branches 
of the spanning tree. Nodes in the network use a 
"BACKWARD LEARNING" technique to route packets along 
the branches of the spanning tree. 

Devices in the spanning tree are logically 
categorized as one of the following three node types: 

1) Root (or root bridge) - A controller device 
which functions as the root bridge of the 
network spanning tree. In the preferred 
embodiment, the spanning tree has a single root 
node. Initially, all controllers are root 
candidates from which a root node is selected. 
This selection may be based on the hopping 
distance to the host, preset priority, random 
selection, etc. 

2) Bridge - An internal node in the spanning 
tree which is used to "bridge" terminal nodes 
together into an interconnected network. The 
root node is also considered a bridge and the 
term "bridge" may be used to refer to all non- 
terminal nodes or all non-terminal nodes except 
the root, depending on the context herein. A 
bridge node consists of a network interface 
function and a routing function. 

3) Terminal - leaf node in the spanning tree. 
A terminal node can be viewed as the software 
entity that terminates a branch in the spanning 
tree. 

A controller device contains a terminal node(s) 
and a bridge node. The bridge node is the root node 
if the controller is functioning as the root bridge. 
A base station contains a bridge node. A terminal 
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device contains a terminal node and must have a 
network interface function, A "bridging entity" 
refers to a bridge node or to the network interface 
function in a terminal. 
5 The basic requirements of the system are the 

following. 

a) Wired or wireless node connections. 

b) Network layer transparency. 

c) Dynamic/automatic network routing 
10 configuration. 

d) Terminal mobility. Terminals should be able 
to move about the RF network without losing an end-to- 
end connection. 

e) Ability to accommodate sleeping terminals. 
!5 f ) Ability to locate terminals quickly. 

g) Built-in redundancy. Lost nodes should have 
minimal impact on the network. 

h) Physical link independence. The bridging 
algorithm is consistent across heterogeneous physical 

20 links. 

The software for the spread-spectrum system is 

functionally layered as follows. 

Medium Access Control fMACl 

25 The MAC layer is responsible for providing 

reliable transmission between any two nodes in the 
network (i.e. terminal-to-bridge). The MAC has a 
channel access control component and a link control 
component. The link control component facilitates and 

30 regulates point-to-point frame transfers in the 

absence of collision detection. The MAC channel 
access control component regulates access to the 
network. Note that herein, the MAC layer is also 
referred to as the Data Link layer. 
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The bridging layer, which is also referred to 
herein as the network layer, has several functions as 
follows. 

1. The bridging layer uses a "HELLO protocol" 
to organize nodes in the network into an optimal 
spanning tree rooted at the root bridge. The spanning 
tree is used to prevent loops in the topology, 
interior branches of the spanning tree are relatively 
stable (i.e. controller and relay stations do not move 
often) . Terminals, which are leaves on the spanning 
three, may become unattached, and must be reattached, 
frequently. 

2. The bridging layer routes packets from 
terminals to the host, from the host to terminals, and 
from terminals to terminals along branches of the 

spanning tree. 

3. The bridging layer provides a service for 
storing packets for SLEEPING terminals. Packets which 
cannot be delivered immediately can be saved by the 
bridging entity in a parent node for one or more HELLO 
times. 

4. The bridging layer propagates lost node 
information throughout the spanning tree. 

5. The bridging layer maintains the spanning 

tree links. 

6. The bridging layer distributes network 
interface addresses. 



30 Tr orrj«a1 Li^ r n p<-rol Laver 

A logical link control layer, also known herein 
as the Transport layer herein, is responsible for 
providing reliable transmission between any two nodes 
in the network (i.e., terminal-to-base station) . The 

35 data-link layer provides a connection-oriented 
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reliable service and a connectionless unreliable 
service. The reliable service detects and discards 
duplicate packets and retransmits lost packets. The 
unreliable services provides a datagram facility for 
5 upper layer protocols which provide a reliable end-to- 

end data path. The data-link layer provides ISO layer 
2 services for terminal-to-host application sessions 
which run on top of an end-to-end terminal-to-host 
transport protocol. However, the data-link layer 
10 provides transport (ISO layer 4) services for sessions 

contained within the SST network. 

Higher layers 

For terminal-to-terminal sessions contained 

15 ' within the SST network, the data-link layer provides 
transport layer services and no additional network or 
transport layer is required. In this case, the MAC, 
bridging, and data-link layers discussed above can be 
viewed as a data-link layer, a network layer, and a 

20 transport layer, respectively. For terminal-to-host- 

application sessions, higher ISO layers exist on top 
of the SST data-link layer and must be implemented in 
the germinal and host computer, as required. This 
document does not define (or restrict) those layers. 

25 This document does discuss a fast-connect VMTP-like 

transport protocol which is used for transient 
internal terminal-to-terminal sessions. 

Specifically, a network layer has several 
functions, as follows. 

30 1) The network layer uses a "hello protocol" to 

organize nodes in the network into an optimal spanning 
tree rooted at the controller. (A spanning tree is 
required to prevent loops in the topology ♦) Interior 
branches of the spanning tree are relatively stable 

35 (i.e., the controller and base stations do not move 
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often) . Terminals, which are leaves on the spanning 
tree, become unattached, and must be reattached 
frequently. 

2) The network layer routes messages from 
terminals to the host, from the host to terminals, and 
from terminals to terminals along branches of the 

spanning tree. 

3) The network layer provides a service for 
storing messages for SLEEPING terminals. Messages 
which cannot be delivered immediately can be saved by 
the network entity in a parent node for one or more 

hello times. 

4) The network layer propagates lost node 

information throughout the spanning tree. 

5) The network layer maintains the spanning 
tree links in the absence of regular data traffic. 

A transport layer is responsible for establishing 
and maintaining a reliable end-to-end data path 
between transport access points in any two nodes in 
the network. The transport layer provides unreliable, 
reliable and a transaction-oriented services. The 
transport layer should be immune to implementation 
changes in the network layer. 

The responsibilities of the transport layer 

25 include the following. 

1) Establishing and maintaining TCP-like 
connections for reliable root-to-terminal data 

transmission. 

2) Maintaining VMTP-like transaction records 
30 for reliable transient message passing between any two 

nodes. 

3) Detecting and discarding duplicate packets. 

4) Retransmitting lost packets. 

Layers 1 through 4 are self-contained within the 
35 Norand RF network, and are independent of the host 



20 



PCT/US92/08610 



- 21 - 

computer and of terminal applications. The session 
layer (and any higher layers) are dependent on 
specific applications. Therefore , the session 
protocol (and higher protocols) must be implemented as 
required. Note that a single transport access point 
is sufficient to handle single sessions with multiple 
nodes. Multiple concurrent sessions between any two 
nodes could be handled with a session identifier in a 
session header. 

Network address requirements are as follows. DLC 
framed contain a hop destination and source address in 
the DLC header, network packets contain an end-to-end 
destination and a source address in the network 
header. Transport messages do not contain an address 
field; instead, a transport connection is defined by 
network layer source and destination address pairs. 
Multiple transport connections require multiple 
network address pairs. 

The transport header contains a TRANSPORT ACCESS 
POINT identifier. DLC and network addresses are 
consistent and have the same format. Each node has a 
unique LONG ADDRESS which is programmed into the node 
at the factory. The long address is used only to 
obtain a SHORT ADDRESS from the root node. 

The network entity in each node obtains a SHORT 
ADDRESS from the root node, which identifies the node 
uniquely. The network entity passes the short address 
to the DLC entity. Short addresses are used to 
minimize packet sizes. 

Short addresses consist of the following. There 
is: an address length bit (short or long) . 

a spanning tree identified. 

a node-type identifier. Node types are well 
known. 

a unique multi-cast or broadcast node identifier. 
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The node-identifier parts of root addresses are 
well known and are constant. A default spanning tree 
identifier is well known by all nodes. A non-default 
spanning tree identifier can be entered into the root 
node (i.e., by a network administrator) and advertised 
to all other nodes in "hello" packets. The list of 
non-default spanning trees to which other nodes can 
attach must be entered into each node. 

A node-type identifier of all l's is used to 
specify all node types. A node identifier of all l's 
is used to specify all nodes of the specified type. 
A DLC identifier of all O's is used to specify a DLC 
entity which does not yet have an address. The all- 
ocs address is used in DLC frames that are used to 
send and receive network ADDRESS packets. (The 
network entity in each node filters ADDRESS packets' 
based on the network address.) 

Short-address allocation is accomplished as 
follows. Short node identifiers of root nodes are 
well known. All other nodes must obtain a short node 
identifier from the root. To obtain a short address, 
a node send an ADDRESS request packet to the root 
node. The source addresses (i.e., DLC and network) in 
the request packet are LONG ADDRESSES. The root 
25 maintains an address queue of used and unused SHORT 

ADDRESSES, If possible, the root selects an available 
short address, associates the short address with the 
long address of the requesting node, and returns the 
short address to the requesting node in an ADDRESS 
30 acknowledge packet. (Note that the destination 

address in the acknowledge packet is a long address.) 

A node must obtain a (new) short address 
initially and whenever an ADDRESS-TIMEOUT inactivity 
period expires without having the node receive" a 
35 packet from the network entity in the root. 
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The network entity in the root maintains 
addresses in the address queue in least recently used 
order. Whenever a packet is received, the source 
address is moved to the end of the queue. The address 
at the head of the queue is available for use by a 
requesting node if it has never been used or if it has 
been inactive for a MAX-ADDRESS-LIFE time period. 

MAX-ADDRESS-LIFE must be larger than ADDRESS- 
TIMEOUT to ensure that an address is not in use by any 
node when it becomes available for another node. If 
the root receives an ADDRESS request from a source for 
which an entry exists in the address queue, the root 
simply updates the queue and returns the old address. 

The network layer organizes nodes into an optimal 
spanning tree with the controller at the root of the 
tree. (Note that the spanning three identifier allows 
two logical trees to exist in the same coverage area. ) 
Spanning tree organization is facilitated with a HELLO 
protocol which allows nodes to determine the shortest 
path to the root before attaching to the spanning 
tree. All messages are routed along branches of the 
spanning tree. 

Nodes in the network are generally categorized as 
ATTACHED or UNATTACHED. Initially, only the root node 
is attached. A single controller may be designated as 
the root, or multiple root candidates (i.e. 
controllers) may negotiate to determine which node is 
the root. Attached bridge nodes and root candidates 
transmit "HELLO" packets at calculated intervals. The 
HELLO packets include: 

a) the source address, which includes the 

spanning tree ID) . 

b) a broadcast destination address. 

c) a "seed" value from which the time schedule 
of future hello messages can be calculated. 
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d) a hello slot displacement time specifying an 
actual variation that will occur in the scheduled 
arrival of the very next hello message (the scheduled 
arrival being calculated from the "seed") . 
5 e) the distance (i.e., path cost) of the 

transmitter from the host. The incremental portion of 
the distance between a node and its parent is 
primarily a function of the type of physical link 
(i.e., ethernet, RS4S5, RF, or the like). If a 

10 signal-strength indicator is available, connections 

are biased toward the link with the best signal 
strength. The distance component is intended to bias 
path selection toward (i.e., wired) high-speed 
connections. Setting a minimum signal strength 

15 threshold helps prevent sporadic changes in the 

network. In addition, connections can be biased to 
balance the load (i.e., the number of children) on a 

parent node. 

f ) a pending message list. Pending message lists 
consist of 0 or more destination-address/message- 
length pairs. Pending messages for terminals are 
stored in the terminal's parent node. 

g) a detached-node list. Detached-node lists 
contain the addresses of nodes which have detached 

25 from the spanning tree. The root maintains two lists. 

A private list consists of all detached node 
addresses, and an advertised list consists of the 
addresses of all detached nodes which have pending 
transport messages. The addresses in the hello packet 

30 are equivalent to the advertised list. 

An internal node learns which entries should be 
in its list from hello messages transmitted by its 
parent node. The root node builds its detached-node 
lists from information received in DETACH packets. 
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Entries are included in hello messages for DETACH-MSG- 
LIFE hello times. 

Attached notes broadcast "SHORT HELLO" messages 
immediately if they receive an "HELLO. request" packet 
with a global destination address; otherwise, attached 
nodes will only broadcast hello messages at calculated 
time intervals in "hello slots." Short hello messages 
do not contain a pending-message or detached-node 
list. Short hello messages are sent independently of 
regular hello messages and do not affect regular hello 
timing. 

Unattached nodes (nodes without a parent in the 
spanning tree) are, initially, in an "UNATTACHED 
LISTEN" state. During the listen state, a node learns 
which attached base station/controller is closest to 
the root node by listening to hello messages. After 
the listening period expires an unattached node sends 
an ATTACH. request packet to the attached node closest 
to the root. The attached node immediately 
acknowledges the ATTACH, request, and send the 
ATTACH. request packet onto the root (controller) node. 
The root node returns the request as an end-to-end 
ATTACH. confirm packet. If the newly-attached node is 
a base station, the node calculates its link distance 
and adds the distance to the distance of its parent 
before beginning to transmit hello messages. 

The end-to-end ATTACH. request functions as a 
discovery packet, and enables the root node to learn 
the address of the source node quickly. The end-to- 
end ATTACH, request, when sent from a node to the 
root, does not always travel the entire distance. 
When a downstream node receives an ATTACH. request 
packet and already has a correct routing entry for the 
associated node, the downstream node intercepts the 
request and returns the ATTACH. confirm to the source 
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node. (Note that any data piggy-backed on the 
ATTACH.reguest packet must still be forwarded to the 
host.) This situation occurs whenever a "new" path 
has more than one node in common with the "old" path. 
5 The LISTEN state ends after MINHELLO hello time 

slots if hello messages have been received from at 
least one node. If no hello messages have been 
received the listening node waits and retries later. 
An attached node may respond to a hello message 

10 from a node other than its parent (i.e., with an 

ATTACK.request) if the difference in the hop count 
specified in the hello packet exceeds a CHANGE- 
THRESHOLD level. 

Unattached nodes may broadcast a GLOBAL 

15 ATTACK.request with a multi-cast base station 

destination address to solicit short hello messages 
from attached base stations. The net effect is that 
the LISTEN state may (optionally) be shortened. (Note 
that only attached base station or the controller may 

20 respond to ATTACH, requests.) Normally, this facility 

is reserved for base stations with children and 
terminals with transactions in progress. 

ATTACH, requests contain a (possibly empty) CHILD 
LIST, to enable internal nodes to update their routing 

25 tables. ATTACH. requests also contain a "count" field 

which indicates that a terminal may be SLEEPING. The 
network entity in the parent of a SLEEPING terminal 
con temporarily store messages for later delivery. If 
the count field is non-zero, the network entity in a 

30 parent node will store pending messages until 1) the 

message is delivered, or 2) ••count" hello times have 
expired. 

Transport layer data can be piggy-backed on an 
attached request packet from a terminal. (i.e., an 
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attach request/ confirm can be implemented with a bit 
flag in the network header of a data packet.) 

Network layer routing. 
5 All messages are routed along branches of the 

spanning tree. Base stations "learn" the address of 
terminals by monitoring traffic from terminals (i.e., 
to the root). When a base station receives (i.e., an 
ATTACH -request) packet, destined for the root, the 

10 base station creates or updates an entry in its 

routing table for the terminal. The entry includes 
the terminal address, and the address of the base 
station which sent the packet (i.e. , the hop address) . 
When a base station receives an upstream packet (i.e. , 

15 from the root, destined for a terminal) the packet is 

simply forwarded to the base station which is in the 
routing entry for the destination. Upstream messages 
(i.e., to a terminal) are discarded whenever a routing 
entry does not exist. Downstream messages (i.e. , from 

20 a terminal to the root) are simply forwarded to the 

next downstream node (i.e., the parent in the branch 
of the spanning tree. 

TERMINAL-TO-TERMINAL COMMUNICATIONS is 
accomplished by routing all terminal-to-terminal 

25 traffic through the nearest common ancestor. In the 

worst case, the root is the nearest common ancestor. 
A "ADDRESS SERVER" facilitates terminal-to-terminal 
communications (see below) • 

DELETING INVALID ROUTING TABLE ENTRIES is 

30 accomplished in several ways: connection oriented 

~~~ transport layer ensures that packets will arrive from 
nodes attached to the branch of the spanning tree 
within the timeout period, unless a node is 
disconnected • ) 
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2) Whenever the DLC entity in a parent fails 
RETRY MAX times to send a message to a child node, the 
node is logically disconnected from the spanning tree, 
with one exception. If the child is a SLEEPING 
terminal, the message is retained by the network 
entity in the parent for "count" hello times. The 
parent immediately attempts to deliver the message 
after it sends its next hello packet. If, after 
"count" hello times, the message cannot be delivered, 
then the child is logically detached from the spanning 
tree. Detached node information is propagated 
downstream to the root node, each node in the path of 
the DETACH packet must adjust its routing tables 
appropriately according to the following rules: a) if 
the lost node is a child terminal node, the routing 
entry for the terminal is deleted and a DETACH packet 
is generated, b) if the node specified in DETACH 
packet is a terminal and the node which delivered the 
packet is the next hop in the path to the terminal, 
then the routing table entry for the terminal is 
deleted and the DETACH packet is forwarded, c) if the 
lost node is a child base station node then all 
routing entries which specify that base station as the 
next hop are deleted and a DETACH packet is generated 
25 for each lost terminal. 

IN GENERAL, WHENEVER A NODE DISCOVERS THAT A 
TERMINAL IS DETACHED, IT PURGES ITS ROUTING ENTRY FOR 
THE TERMINAL. WHENEVER A NODE DISCOVERS THAT A BASE 
STATION IS DETACHED, IT PURGES ALL ROUTING ENTRIES 
30 CONTAINING THE BASE STATION. ONLY ENTRIES FOR 

UPSTREAM NODES ARE DELETED. 

When DETACH packets reach the root node, they are 
added to a "detached list." Nodes remain in the root 
node's detached list until a) the node reattaches to 
35 the spanning tree, or b) the list entry times out. 
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The detached list is included in hello messages and is 
propagated throughout the spanning tree. 

For example , if a terminal detaches and 
reattaches to a different branch in the spanning tree, 
5 all downstream nodes in the new branch (quickly) 

"learn" the new path to the terminal. Nodes which 
were also in the old path change their routing tables 
and no longer forward packets along the old path. At 
least one node, the root, must be in both the old and 
10 new path. A new path is established as soon as an 

end-to-end attach request packet from the terminal 
reaches a node which was also in the old path. 

4) A node (quickly) learns that it is detached 
whenever it receives a hello message, from any node, 

15 with its address in the associated detached list. The 

detached node can, optionally, send a global 
ATTACH. request, and then enters the UNATTACHED LISTEN 
state and reattaches as described above. After 
reattaching, the node must remain in a HOLD-DOWN state 

20 until its address is aged out of all detached lists. 

During the HOLD-DOWN state the node ignores detached 
lists. 

5) A node becomes disconnected and enters the 
UNATTACHED LISTEN state whenever HELLO-RETRY-MAX hello 

25 messages are missed from its parent node. 

6) A node enters the ATTACHED LISTEN state 
whenever a single hello message, from its parent, is 
missed. SLEEPING terminals remain awake during the 
ATTACHED LISTEN state . The state ends when the 

30 terminal receives a data or hello message from its 

parent. The terminal becomes UNATTACHED when a) its 
address appears in the detached list of a hello 
message from an ode other than its parent, or b) 
HELLO-RETRY-MAX hello messages are missed. The total 
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number of hello slots spend in the LISTEN state is 
constant. 

If a node in the ATTACHED LISTEN state discovers 
a path to the root which is CHANGE-THRESHOLD shorter, 
5 it can attach to the shorter path. Periodically, 

SLEEPING terminals must enter the ATTACHED LEARN state 
to discovery any changes (i.e. , shorter paths) in the 
network topology. 

10 Hello synchronization. 

All attached non-terminal nodes broadcast 
periodic "hello- messages in discrete "hello slots" at 
calculated intervals. Base station nodes learn which 
hello slots are busy and refrain from transmitting 

15 during busy hello slots. 

A terminal refrains from transmitting during the 
hello slot of its parent node and refrains from 
transmitting during message slots reserved in a hello 
message. 

20 The hello message contains a "seed- field used in 

a well-known randomization algorithm to determine the 
next hello slot for the transmitting node and the next 
seed. The address of the transmitting node is used as 
a factor in the algorithm to guarantee randomization. 

25 Nodes can execute the algorithm i times to determine 

the time (and seed) if the i-the hello message from 

the transmitter. 

After attached, a base station chooses a random 
initial seed and a non-busy hello slot and broadcasts 
a hello message in that slot. The base station 
chooses succeeding hello slots by executing the 
randomization algorithm. If an execution of the 
algorithm chooses a busy slot, the next free slot is 
used and a hello "displacement" field indicates the 
offset from a calculated slot, cumulative delays are 
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not allowed (i.e., contention delays during the i 
hello transmission do not effect the time of the i+1 
hello transmission) • 

HELLO-TIME and HELLO-SLOT-TIME values are set by 
the root node and flooded throughout the network in 
hello messages. The HELLO-SLOT-TIME value must be 
large enough to minimize hello contention. 

A node initially synchronizes on a hello message 
from its parent. A SLEEPING node can power-down with 
an active timer interrupt to wake it just before the 
next expected hello message. The network entity in 
base station nodes can store messages for SLEEPING 
nodes and transmit them immediately following the 
hello messages. This implementation enables SLEEPING 
terminals to receive unsolicited messages. (Note that 
the network layer always tries to deliver messages 
immediately, before storing them.) Retries for 
pending messages are transmitted in a round-robin 
order when messages are pending for more than one 
destination. 

Note that a child node that misses i hello 
messages , can calculate the time of the i+1 hello 
message. 

Transport layer theory and implementation notes. 

The transport layer provides reliable, 
unreliable, and transaction-oriented services. Two 
types of transport connections are defined: 1) a TCP- 
like transport connection may be explicitly requested 
for long-lived connections or 2) a VMTP-like 
connection-record may be implicitly set up for 
transient connections. In addition, a connectionless 
service is provided for nodes which support an end-to- 
end transport connection with the host computer. 
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The interfaces to the next upper (i.e., 
application) layer include: 

CONNECT (access_point, node_name) 
LISTEN (access_point) 

UNITDATA (accessjpoint, nodejiame, buffer, 
length) 

SEND (handle, buffer, length) 
RECEIVE (handle, buffer, length) 
CLOSE (handle) 

The "handle" designates the connection type, and 
is the connection identifier for TCP-like connections. 

SEND messages require a response from the network 
node (root or terminal) to which the message is 
directed. 

UNITDATA messages do not require a response. 
UNITDATA is used to send messages to a host which is 
capable of supporting end-to-end host-to-terminal 
transport connections. 

Because the network layer provides an unreliable 
service, the transport layer is required to detect 
duplicate packets and retransmit lost packets. 
Detecting duplicates is facilitated by numbering 
transport packets with unambiguous sequence numbers. 

25 Transport connections. 

TCP-like transport connections are used for 
message transmission over long-lived connections . The 
connections may be terminal-to-root or terminal-to- 
terminal (i.e., base stations are not involved in the 

30 transport connection) . 

TCP-like transport connections are established 
using a 3-way handshake. Each end selects its initial 
sequence number and acknowledges the other end's 
initial sequence number during the handshake. The 

35 node which initiates the connection must wait a MAX- 
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PACKET-LIFE time, before requesting a connection, to 
guarantee that initial sequence numbers are 
unambiguous. Sequence numbers are incremented modulo 
MAX-SEQ, where MAX-SEQ is large enough to insure that 
5 duplicate sequence numbers do not exist in the 

network. Packet types for establishing and breaking 
connections are defined as in TCP. 

A TCP-like connection is full-duplex and a 
sliding window is used to allow multiple outstanding 

10 transport packets. An ARQ bit in the transport header 

is used to require an immediate acknowledgment from 
the opposite end. 

VMTP-like connections are used for transient 
messages (i.e. terminal-to-terminal mail messages). 

15 VMTP-like connection records are built automatically. 

A VMTP-like connection record is built (or updated) 
whenever a VMTP-like transport message is received. 
The advantage is that an explicit connection request 
is not required. The disadvantage is that longer and 

20 more carefully selected sequence numbers are required. 

A VMTP-like connection is half -duplex. (A full-duplex 
connection at a higher layer can be built with two 
independent half -duplex VMTP-like connections.) 
Acknowledgments must be handled by higher layers. 

25 Transport connections are defined by the network 

end-to-end destination and source addresses. 

A MAX_TP_LIFE timeout is associated with 
transport connections. Transport connection records 
are purged after a MAX_TP_LIFE time expires without 

30 activity on the connection. The transport entity in 

a terminal can ensure that its transport connection 
will not be lost by transmitting an empty time-fill 
transport packet whenever TP_TIMEOUT time expires 
without activity. 



WO 93/07691 



PCT/US92/08610 



- 34 - 



The transport entity in a node stores messages 
for possible retransmission. Note that 

retransmissions may not always follow the same path 
(primarily) due to moving terminals and the resulting 
5 changes in the spanning tree.- For example; the 

network entity in a parent node may disconnect a child 
after the DLC entity reports a message delivery 
failure. The child will soon discover that it is 
detached and will reattach to the spanning tree. Now 
10 when the transport entity (i.e. in the root) re-sends 

the message, it will follow the new path. 

Transport message timing and sleeping terminals. 

The transport entity in a terminal calculates a 

15 separate timeout for SEND and TRANSACTION operations. 

initially, both timeouts are a function of the 
distance of the terminal from the root node. 

A TCP-like algorithm is used to estimate the 
expected propagation delay for each message type. 

20 Messages, which require a response, are retransmitted 

if twice the expected propagation time expires before 
a response is received. SLEEPING terminals can power 
down for a large percentage of the expected 
propagation delay before waking up to receive the 

25 response message. Note that missed messages may be 

stored by the network layer for "count" hello times. 

Medium Access Control (MAC) theory and implementation 
notes. 

30 Access to the network communications channel is 

regulated in several ways: executing the full CSMA 
algorithm (see MAC layer above). The sender 
retransmits unacknowledged messages until a RETRY_MAX 
count is exhausted. 
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The retry time of the DLC must be relatively 
short so that lost nodes can be detected quickly. 
When the DLC layer reports a failure to deliver a 
message to the network layer , the network layer can 1) 
5 save messages for SLEEPING terminals fojf later 

attempts, or 2) DETACH the node from the spanning 
tree. Note that most lost nodes are' due to moving 
terminals. 

The node identifier part of the DLC address is 
10 initially all 0*s for all nodes except the root node. 

The all O's address is used by a node to send and 
received data-link frames until a unique node 
identifier is passed to the DLC entity in the node. 
(The unique node identifier is obtained by the network 
15 entity.) 



Address resolution. 

Well-known names too are bound to network 
addresses in several ways: 
20 - The network address and TRANSPORT ACCESS 

ID of a name server, contained in the root, is 
well-known by all nodes. 

- A node can register a well-known name 
with the name server contained in the root node. 
25 - A node can request the network access 

address of another application from the name 
server by using the well-known name of the 
application. 

30 Possible extensions. 

Base station-to-base station traffic could also 
be routed through the controller if the backward 
learning algorithm included base station nodes. (Each 
base station would simply have to remember which 
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direction on its branch of the spanning tree to send 
data directed toward another base station.) 

The possibility of multiple controllers is kept 
open by including a spanning-tree identifier in 
address fields. Each controller defines a unique 
spanning tree. A node can be in more than one 
spanning tree, with separate network state variables 
defined for each. 

Thus, the preferred embodiment of the present 
invention describes an apparatus and a method of 
efficiently routing data through a network of 
intermediate base stations in a radio data 

communication system. 
15 In alternate embodiments of the present 

invention, the RF Networks contain multiple gateways. 
By including a system identifier in the address field 
of the nodes, it is possible to determine which nodes 
are connected to which networks. 

As is evident from the description that is 
provided above, the implementation of the present 
invention can vary greatly depending upon the desired 
goal of the user. However, the scope of the present 
invention is intended to cover all variations and 
substitutions which are and which may become apparent 
from the illustrative embodiment of the present 
invention that is provided above, and the scope of the 
invention should be extended to the claimed invention 
and its equivalents. 
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WHAT IS CLAIMED IS : 

1. A multi-hop data communication network 
having RF capability comprising: 

a host computer node; 

a plurality of terminal nodes; and 
5 a plurality of bridging nodes which 

dynamically create and revise communication pathways 
between any two nodes in the network, each of the 
bridging nodes independently storing and maintaining 
local information that specifies how communication 
10 traffic should flow through that bridging node, and 

the plurality of bridging nodes, together, providing 
a complete specification for the communication 
pathways in the multi-hop communication network. 

2. A multi-hop data communication system 
comprising: 

a root node; 

a plurality of terminal nodes; 
5 a plurality of bridging nodes which 

dynamically arrange communication pathways between the 
root node and the other nodes in the network; and 

said nodes using a backward learning 
technique to independently create and maintain locally 
10 stored information to specify how communication 

traffic should flow through that bridging node. 

3. A data communication system providing 
communication pathways between comprising: 

a plurality of terminal nodes; and 
— * a plurality of bridging nodes dynamically 

5 interconnecting the terminal nodes to provide 

communication pathways between the terminal nodes, 
each of the bridging nodes independently storing and 
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updating local information that specifies the 
communication pathways through that bridging node. 

4. A multi-hop data communication system 
providing communication pathways comprising: ' 

a first communication node; 

a second communication node from which it is 

5 desired to initiate communication with the first 

communication node; 

a plurality of intermediate communication 

nodes; and 

the communication nodes dynamically 
10 arranging communication pathways to provide a minimum 

number of hops between the first and second nodes 
without overloading any one intermediate node. 

5. & multi-hop data communication system 
providing communication pathways comprising: 

a first and a second communication node 
between which communication is desired; 
5 a plurality of intermediate communication 

nodes; 

said communication nodes using backward 
learning techniques dynamically interconnecting the 
first and second communication nodes to provide a 
10 communication pathway with the lowest number of hops 

possible without overloading any one intermediate 
communication node; and 

said communication nodes maintaining current 
information specifying how communication traffic 
15 should flow therethrough. 

6. In a multi-hop data communication 
system having a computer node and a plurality of 
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communication nodes, a method for providing 
communication among the nodes comprising the steps of: 
5 (a) establishing a communication link 

between the computer node and one of the plurality of 
communication nodes; 

(b) indicating from the communication node 
which has been linked to those of the remaining, 

10 unlinked communication nodes that a communication link 

has been established; 

(c) establishing a communication link 
between the unlinked communication nodes which receive 
the indication and the linked communication node; 

15 (d) repeating steps (b) and (c) for each 

communication node which has established a 
communication link until all of the plurality of 
communication nodes have been linked; and 

(e) requesting, by any of the communication 

20 nodes which become unlinked, a communication link and 

branching to step (b) . 

7, In a multi-hop data communication 
system having a first and second communication node 
and a plurality of intermediate communication nodes, 
a method for providing communication pathways among 
5 the communication nodes comprising the steps of: 

(a) establishing for the first 
communication node a communication link with at least 
one of the plurality of intermediate communication 
nodes ; 

10 (b) indicating by each of the linked 

intermediate communication nodes that a communication 
link has been established and providing the hopping 
distance of that link; 

(c) analyzing, by the intermediate 

15 communication nodes which receive the indication and 
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by the second communication node if it receives the 
indication, the indication to determine whether to 
establish a communication link with the intermediate 
communication node providing the indication, and, if 
20 the analysis so indicates, establishing - the 

communication link; 

(d) branching to step (b) if the second 
communication node has not been linked; and 

(e) requesting, by any of the communication 
25 nodes which become unlinked, a communication link and 

branching to step (b) . 

8. in a multi-hop data communication 
system having a root node and a plurality of 
communication nodes a method for providing and 
maintaining communication pathways among the nodes 

5 comprising the steps of: 

(a) indicating by the root node that 
communication links may be established; 

(b) analyzing, by the communication nodes 
which receive the indication, the indication to 

10 determine whether to establish a communication link 

with the root node providing the indication, and, if 
the analysis so indicates, establishing the 
communication link; 

(c) indicating by each of the linked 
15 communication nodes the hopping distance of the link 

to the root node; 

(d) analyzing, by the communication nodes 
which receive the indication, the indication to 
determine whether to establish a communication link 

20 with the linked communication node providing the 

indication, and, if the analysis so indicates, 
establishing the communication link; 
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(e) branching to step (c) until all 
intermediate communication nodes have been linked; and 
25 (f ) requesting, by any of the intermediate 

nodes which become unlinked, a communication link and 
branching to step (c) . 

9, In a multi-hop data communication 
system having a root node, a plurality of 
communication nodes, and a plurality of terminal nodes 
a method for providing communication pathways among 
5 the communication nodes comprising the steps of: 

(a) indicating by the root node a readiness 
to establish communication links; 

(b) establishing communication links 
between the root node and the communication nodes 

10 receiving the indication; 

(c) indicating by each of the linked 
communication nodes the number of communication links 
which have been established and providing the hopping 
distance of the link to the root node; 

15 (d) analyzing, by the communication nodes 

which receive the indication, the indication to 
determine whether to establish a communication link 
with the linked communication node providing the 
indication, and, if the analysis so indicates, 

20 establishing the communication link; 

(e) branching to step (c) until all 
communication nodes have been linked; 

(f ) indicating by the linked communication 
nodes the hopping distance of the link to the root 

25 node; 

(g) analyzing, by the plurality of terminal 
nodes, the indications which are received to determine 
which linked communication nodes to establish, and, 
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each terminal node establishing at least one 

30 communication link; 

(h) requesting, by any of the plurality of 
terminal nodes which become unlinked, a communication 
link and branching to step (£) ; and 

(i) requesting, by any communication node 
which becomes unlinked, a communication link and 
branching to step (c) . 

10. In a multi-hop data communication 
system having a plurality of communication nodes, a 
method for providing communication pathways among the 
communication nodes comprising the steps of: 

(a) selecting one of the communication 

nodes to be a root node; 

(b) indicating by the root node that 
communication links may be established; 

(c) establishing communication links 
between the root node and the communication nodes 
receiving the indication; 

(d) indicating by each of the linked 
communication nodes the hopping distance of the link 
to the first communication node; 

(e) analyzing, by the linked communication 
nodes which receive each indication, the indications 
to determine whether to replace the current 
communication link with a link to the communication 
node providing the indication, and, if the analysis so 
indicates, replacing the communication link; 

(f) analyzing, by the unlinked 
communication nodes which receive each indication, the 
indications to determine whether to establish a 
communication link with the communication node 
providing the indication, and, if the analysis so 
indicates, establishing the communication link; 
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(g) branching to step (c) until 
communication nodes have been linked. 
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